Software applications are often developed following specific requirements to provide certain capabilities. Although a software application developer may provide end users with valuable functionality, third party script developers may enhance this basic functionality by providing extensions, automations, plugins, or similar code which change or extend software application functionality, making the application more user-friendly. For example, web application developers may create a software application for sending and receiving email. The web application may include functionality for finding and labeling email. The application may also have a limit on the size capacity of any one end user's email account. However, the web application may not provide end users with the ability to find email messages over a certain size so that they can delete large email messages to free up space in their email account. A third party script developer may write a plugin that, when added to the email application, can find and label all email messages over a certain size. An end user can add the third party developer's plugin to his or her browser and run the plugin to easily find large email messages so that these messages can be deleted when the end user's email account reaches size capacity.
Even though third party scripts can improve end user experiences, very few software application developers allow untrusted third party scripts to be added to their web applications because adding third party functionality makes it difficult for a web application developer to maintain web application security and also makes end users' experiences with the web application inconsistent.
As illustrated in FIG. 1, customary third party scripts (105) most often work at the web browser-level (101a, 101b) and are not an integral part of software applications. A notable example of browser-level third party scripts is a plugin, which is a software component that can customize functionality of a web application. Browser-level scripts are problematic because they are browser-dependent. If an end user installs a script such as the one shown in FIG. 1 (105) for an application (103a) in one browser (101a), but then changes the browser (101b) that he or she is using to access a different instance of the same application (103b), the end user must install the script in the new browser in order to obtain the script's functionality for the application. As shown in FIG. 1, script 105's functionality extension of the application is available in browser 1 (101a), but not in browser 2 (101b) since the script is not installed in browser 2 (101b).
There should be a system that allows third-party script to closely interact with a host application while still remaining secure. The system should allow software application developers to securely add third-party scripting functionality to their hosted applications so that the third-party scripts can be associated with an end user regardless of how the end user is accessing the application.